はじめに
プラットフォーム開発チームのyoshinoです。
現在、GitHubへの情報集約を進めており、その第一弾としてチケット管理をNotionからGitHub Projectsに移行しました。開発チームだけでなくビジネスサイドも巻き込んだ移行から約5ヶ月経ったので、移行しようと思ったきっかけや現在どうやって運用しているか、移行して何が良かったかまでをメモがてら記事にしようと思います。
TL;DR
- AIエージェントがより自律的にタスクに取り組める環境を作るため、チケット管理をNotion/スプレッドシートからGitHub Projectsに移行した
- Issueの起票など様々なイベントを起点としてAIエージェントにタスクを実行させる仕組みを作った
- チケットの起票・編集・コメントまでもがAIエージェント経由で完結するようになり、開発体験が大幅に向上した
AI活用は進んでいたが…
移行を考え始めた2025年10月以前から、チームではClaude Code、CursorといったAIエージェントを使って開発タスクをこなすことは当たり前になっていました。AI活用が一定の成熟フェーズに入ってきた一方で、より開発生産性を向上させるには、AIエージェントが必要なコンテキストに自らアクセスできる環境を整える必要があると感じるようになりました。
当時、開発チケットはNotion、ビジネスサイドからの不具合報告や機能要望はスプレッドシートで管理しており、プロダクトに関する情報が複数のツールに分散している状態でした。
この環境にはいくつかの課題がありました。
まず、チケット起票を起点としたイベント駆動の自動化ができないこと。例えば、文言修正のような軽微な修正チケットはクラウド上でDevinなどのツールを使って対応させたいのですが、Notionやスプレッドシートでは柔軟な自動化が難しく、実現できませんでした。
次に、AIエージェントとの連携の問題。NotionにはMCPサーバーが存在するものの、当時はチケット管理の用途で実用的とは言えませんでした。スプレッドシートに至ってはそもそもチケット管理ツールとしての構造的な限界があり、AI連携以前の話でした。
また、Notionとスプレッドシートでチケットが分かれていること自体が、情報の一元管理を妨げており、ツールの棲み分けも曖昧で運用負荷がかかっている状態でした。
結果として、チケットが起票されるたびに人間が内容を確認し、手動でAIエージェントに渡すという運用が続いていました。Kaname.axの開発が社内展開に向けて佳境を迎えており、開発効率を最大化したいタイミングでこれらの課題が重なり、本腰を入れて移行を推進することにしました。
なぜGitHubなのか
前セクションで挙げた課題を解決する上で、以下の3つの理由からGitHubが最適だと判断しました。
1つ目は、コンテキストの集約です。ソースコードが既にGitHubにあるため、チケットも同じ場所に置けば、Issue → PR → コミット → レビュー → マージの流れが自然につながります。NotionでもGitHubとの連携は可能ですが、あくまで外部連携であり、AIエージェントが参照すべきコンテキストが一箇所に集約されている状態とは異なります。
2つ目は、GitHub ActionsとWebhookの存在です。Issue作成やラベル付与といったイベントをフックに任意の処理を実行できるため、前セクションで触れたイベント駆動でのAIを活用した自動化を実現できます。
3つ目は、GitHub CLIやGitHub MCPサーバーの完成度が高く、AIエージェントとの親和性に優れていることです。
移行にあたって
まずは開発チームで2週間ほど先行して試し、その間に勘所を掴みつつ大枠の運用ルールを策定するなどして受け入れる準備を行いました。ビジネスサイドのメンバーには、AIツールとの親和性を高めることで開発生産性が向上すること、またGitHub自体は開発者向けのプラットフォームですがGitHub Projects自体に関しては一般的なチケット管理ツールと大きく変わらないことを事前に共有し、理解をしてもらった上でスムーズに移行できました。
また、開発チームおよびビジネスサイド双方の移行コストをなるべく抑えるために、既存のスプレッドシートでの運用と同等のUXを再現することを意識しました。具体的には一覧で課題が視認できたり、実際に使っていたステータスをそのまま移植したりしました。さらに、スプレッドシートで不具合課題を管理していた際に起票者によるフォーマットの揺らぎがあったため、それをなくすためにIssueのテンプレートを整備しました。（それぞれ、選択されたテンプレートによって、自動でラベルが付与されるようになっており、後述のDevinを活用したタスク遂行時に役立てています）
テンプレのイメージ
Issueの種別
不具合チケットの場合
GitHub Projectsの使用感
チケット管理に必要な機能は一通り揃っており、不自由なく使えています。Notionで運用していたようなボードビューに加え、目的に応じてビューを分けて運用しています。
大別すると4つの用途でタブを分割しています（この辺もまだ詰めきれていないのでブラッシュアップしていきたい）
- スプリント – 進行中スプリントのタスクを管理するBacklog
- チケット種別 – Epic, Story, Feature, Taskなど
- ビジネス向け – 不具合報告や機能要望など、ビジネスサイドが起票する課題
- 個人、ロール別 – 担当者やデザイン
メインのボード
その他のビュー
AIエージェントの活用
実際にGitHub CLI, GitHub MCPとAIエージェントの親和性を活かして、どう活用しているか一例を紹介します。
Claude CodeでIssueを起票
Issue作成手順
1. 「Issue作成したい」と投げる
2. Issueの種別を提示されるので選択する
3. Claude Codeと対話しながら埋めていく
Devinとの連携
Issueの作成をフックとして、付与されたラベル（不具合、機能要望、仕様確認など）によってそれぞれ専用のプロンプトを用意しており、Devin APIを叩くようになっています。いずれのIssueもまずは調査をさせ、タスクボリュームが軽量であると判断した場合はPR作成まで自律的に行い、逆に変更ファイルが一定以上を超えるとDevin自身が判断した場合はIssueへの調査コメントに留めるようプロンプトを設計しています。開発者が介入せずに、自律してタスクを完遂できることこそがDevinを利用するメリットの一つ（開発者は他のタスクに集中できる）だと考えているので、インタラクティブなやり取りが発生すると判断した時点で、手元のClaude Codeでやるようにツールの棲み分けをしています。
5ヶ月経って
移行して一番良かったのは、GitHub MCP、GitHub CLIを活用したAIエージェントとの連携面です。
これまではNotionでチケットを確認→内容をコピー→エージェントに貼り付けてやらせる、だったのが、今はAIエージェントにIssueのURLを渡すだけで、内容を自分で取得して作業を開始してくれます。必要に応じてIssueの内容を更新するケースも多々あり、それさえもエージェントにさせることができています。（むしろ最近は手動でチケットを起票したりコメントしたりすることのほうが少ない）今では、メンバーがGitHub Projectsでの課題管理に慣れてきて、Issue作成、調査結果のコメント、編集などを全てClaude Code、Cursor経由で行うようになり、開発体験が大幅に向上しています。skillも整備しているので、もはや人間が0からチケット作成するより、AIエージェントにやることと完了条件を箇条書きで投げて、まとめてもらうほうが早いし読みやすいと感じています。
一方で、運用してみて見えてきた改善ポイントなどがいくつかあります。
①AIネイティブな情報フォーマット
Issueのタイトルや中身がAIエージェントが自走してタスク遂行できるだけの十分な情報が揃っているか、の精度検証はまだ十分に出来ていません。現状、skillを使ってIssueのフォーマットは種別ごとに標準化していますが、AIがタスクを遂行する上でさらに必要または不要な情報があるのではないかと感じています。直近だと、AIがソースコードを見れば分かるような情報やHowを詳細に書くことはやめました。
②Issue作成先
一つのProjectに複数リポジトリのIssueが紐づいているので、Issue作成時にリポジトリを指定しないと意図しないところに作ってしまうことがあります。skillで作成前にユーザーに確認を取る、もしくは作成時に選択肢を提示するなどの仕組みで防ぎたいと考えています。
③ラベルの運用ルール
Notion時代からの継続課題ではありますが、ラベルの運用ルールが曖昧で有効活用できていません。意味のあるラベルを定義して、チーム内で共通認識を持てれば、ビューのフィルタリングやツール連携など運用面で恩恵を得られる場面があると考えているので優先的に整備したいと考えています。
まとめ
今後もAIファーストで開発が更に加速する中で、チケット管理をGitHub Projectsへ移行して本当によかったと感じています。
次のフェーズとしてはプロダクトの仕様もGitHubに集約したいと考えており、運用コストが低い仕組みを検討している段階です。AI開発ツール周辺の進化が凄まじく、そっちのキャッチアップで大変ではありますが、スピード感を持って取り組みたいです。
